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ABSTRACT 



Information stored in a corporate database is monitored and 
used to determine when certain business-related events have 
occurred. Event information is transmitted over the Internet 
to a print production facility, where it is used to fire one or 
more event rules, which in turn automatically generate print 
requisitions or print production orders. In one variation, 
print requisitions are routed through an existing and com- 
mercially available procurement system before a print pro- 
duction order is generated. The system can monitor and 
handle events from multiple corporations, each having its 
own business-related event rules, and each potentially hav- 
ing its own procurement approval system. 

29 Claims, 15 Drawing Sheets 
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METHOD OF GENERATING PRINT 

PRODUCTION TASKS USING 
INFORMATION EXTRACTED FROM 
ENTERPRISE DATABASES 

5 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is related in subject matter to co-pending 
U.S. application Ser. No. 09/460,307 now pending; entitled 1Q 
"System and File Structure for Consistent Visual Medium 
Materials," which was filed on Dec. 13, 1999. That appli- 
cation is incorporated by reference herein. 

TECHNICAL FIELD ^ 

This invention generally relates to systems that generate 
printed products, sucb as general office stationery (e.g., 
letterhead, business cards, or envelopes); and high-end mar- 
keting communication materials and other products that use 
digital printing, commercial offset printing, or flexography. 20 
More particularly, the invention provides various systems 
and techniques for using event-driven rules to initiate print- 
production tasks on the basis of data extracted from corpo- 
rate systems or databases such as enterprise resource plan- 
ning systems, human resource management systems, 25 
manufacturing, logistics, or other corporate systems. 

BACKGROUND OF THE INVENTION 

Conventional techniques for generating customized 3Q 
printed products such as business cards, stationery, and other 
personalized and marketing communication materials fre- 
quently employ computers in the production process. In 
FIG. 1, for example, a customer 103 desiring to have 
business cards printed for a new employee typically brings 
or faxes information 104 to a print broker 101, such as a 
local print shop or copy store. An employee 106 creates an 
order for the print product using an ordering computer 105. 
The print order may specify the number of cards to be 
produced, the font styles to be used, and customized content 
such as the employee's name, title, and telephone number. 

The print order created in ordering computer 105 can be 
transmitted to a second facility 102 for preprocessing. The 
order can be transmitted as an ASCII file over a communi- 
cation link 107 to a second computer 108 at the second 45 
facility. A layout computer 108, operated by another 
employee 109, is used to lay-out the content within the space 
and style constraints of the printed medium (e.g., business 
cards of a certain size). Conventional software packages 
such as Pagemaker™ and Quark™ can be used to format the 5Q 
printed product and simulate its appearance before it is 
actually printed. 

The output of the layout computer, which may comprise 
for example a PostScript™ file, is sent to an image setter 
110, which is a device that generates a plate or other medium 55 
that can be directly used by a printing press 111 to produce 
the printed product 112. Depending on the type of print 
medium, the printed product may comprise customized 
paper products, embossed materials, rubber stamps, plaques, 
or the like. Although the conventional arrangement shown in 50 
FIG. 1 is exemplary, the system may be housed in a single 
facility, such that all of the printing tasks occur at a common 
location. 

Large corporations by their nature require large quantities 
of customized printed products, such as business cards, sales 65 
brochures, and letterhead. Each time a new employee joins 
a corporation or a new brochure is needed, the steps shown 
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in FIG. 1 must be carried out. Repeating these steps incurs 
extensive costs due to human involvement (e.g., labor costs) 
and the possibility that errors may be introduced into one or 
more steps. Because of the many steps and human 
involvement, a simple printing job can take days or even 
weeks. 

As one example, an employee's name must be typed or 
printed on an order form, then transferred into an ordering 
computer, and manually entered again into a layout com- 
puter. Every time a human touches the information, the 
process is delayed and the possibility exists that an error will 
be introduced. Additionally, various validation and approval 
procedures must be followed in order to ensure that the 
printed information will be produced correctly, and that only 
certain authorized products are printed. 

Attempts to further automate the foregoing processes are 
complicated by the fact that different print brokers may use 
different formats, techniques, and software products for 
entering data and generating printed products, and the fact 
that different companies store content such as employee 
names and addresses in different ways. Other automation 
barriers are inherent in the distributed and non-uniform 
process steps that are carried out by different print vendors 
and suppliers. Some of these problems arc discussed in more 
detail in co-pending U.S. application Ser. No. 09/460,307, 
filed on Dec. 13, 1999, and incorporated by reference herein. 

One approach for solving some of the foregoing problems 
is to use a centralized print production system that accepts 
print orders over the Internet and allows the customer to 
approve print proofs on-screen. As described in the above- 
referenced patent application, the printing process can be 
simplified by using certain file formats and data processing 
techniques to generate printed products. Nevertheless, fur- 
ther automation is possible. 

Enterprise resource planning systems (ERPs) are conven- 
tionally used to store, track and plan information concerning 
an enterprise, such as a company. For example, many 
companies use human resource management systems that 
store information such as employee names, addresses, titles, 
salaries, and the like. An example of one such system is a 
commercially available product from PeopIeSoft.™ Such 
systems typically perform payroll and accounting functions, 
and other human resource related functions such as organi- 
zational management. Other enterprise resource planning 
systems perform tasks such as tracking and planning sales, 
manufacturing operations, and the like. Companies that do 
not use ERPs may nevertheless store company-wide infor- 
mation in databases that allow the data to be accessed in a 
structured way. 

The aforementioned ERPs and databases have not typi- 
cally been coupled to an automated printing facility of the 
type described above. Even though ERPs and related data- 
bases store extensive company-wide information such as 
employee data, organizational information, inventory and 
manufacturing data, and the like, such ERPs and databases 
have not been linked to an automated print production 
process that could make direct use of the data stored therein. 
Instead, humans still manually generate print production 
requests on the basis of changes to the company's data. 
Because corporate databases and ERPs have historically not 
been directly accessible to outside vendors, it has not been 
feasible to directly translate data stored in such databases 
into print production requests. 

When a new employee is added to a company's database, 
a human resources manager must recognize that event, and 
must manually create a print order for new business cards, 
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name plaques, and letterhead. This manual intervention resources management system, print orders for new business 
provides opportunities for errors to creep into the print cards can be automatically generated whenever a new 
production process, and introduces delays. (For example, if employee is added or when an organizational change occurs, 
the human resources manager is out sick, busy, or on t d a manufacturing environment, print orders can be auto- 
vacation, the order for business cards may be delayed). 5 matically generated when a new design is released for 
Moreover, the labor involved in generating such print orders production or when an order is placed that requires corre- 
is costly, particularly where a company adds dozens of new spon ding printed products. In a sales management system, 
employees on a weekly or monthly basis. customized sales brochures can be automatically printed in 
As another example, suppose that a corporation decides to response to entry of a new sales prospect. In an inventory 
create award plaques, coffee mugs, and specially embossed 10 control system, print orders can be automatically generated 
pins for all sales employees who have exceeded a sales when inventory levels fall be lo w a threshol d, or after a 
quota. The job of creating print orders to generate such s pecified per iod of"ti me has~clapsed (e.g., pnnt new bro- 
printed products would typically fall to a human resources enures every yO days). TrTa publishing environment, reprint 
manager or similar employee, who would query the com- orders for magazine articles and the like can be automati- 
pany's database to identify such sales employees, generate 15 ca ll y generated in response to a reprint order request, or 
a printout of employee information (e.g., name, title, and the wne n the number of reprints in stock falls below a certain 

like), and manually create print orders for the various printed level. Other application areas are also possible. 

products. That task is labor intensive and, as noted above, 

could result in misspelled names or other data errors. BRIEF DESCRIPTION OF THE DRAWINGS 

As yet another example, suppose that a bicycle manufac- 20 FIG. 1 shows a conventional technique for generating a 
hiring company receives an order lo manufacture 5,000 new printed product such as business cards, 
bicycles of a particular model and style. A manager at the FIG. 2 shows a system that monitors changes to a cor- 
manufacturing company must determine when the bicycle porate database and executes rules that automatically gen- 
order will be completed and, based on the schedule, create erate printed products in response to such changes. 
^prirUorde r to have prin ted instructor . manuals^war^ 25 pjQ 3 shows a print prod uction system that uses the 
cardsTand the like generated in time to be included with the lntcrnct {q rammunicatc cvcnl data and obtain procurcment 
manufactured bicycles and shipping boxes. approvals 

SUMMARY OF THE INVENTION FIG. 4 shows a centralized print production system that 

The present invention provides a system and method for 30 detects events occurring at a plurality of companies, wherein 

extracting information from one or more corporate databases one company uses a corporate procurement system through 

and automatically generating print production orders using which print requisitions must be handled while another 

such information. In one embodiment, a set of event defi- company does not use such a procurement system, 

nitions is provided based on changes to data in the corporate FIG. 5 shows a series of steps that can be carried out to 

database. A set of event rules is also defined, such that a print 35 implement a method in accordance with various aspects of 

production request or requisition is automatically generated the invention. 

in response to firing of one or more event rules. The print FIG. 6 shows how fields in different corporate databases 

production request or requisition contains data directly can be mapped to a common data element in a central print 

extracted from the corporate database, rather than being facility, and how certain fields can be mapped to locally 

manually entered by an employee. Ano^ificMio£can^e ^ s t ore d data that is not stored in the corporate database, 

ge nerated that confir ms that the prinH mler was^utbmat i- FIG. 7 shows one possible event rule that can be used lo 

cairy ^nerated3 gLmdic^lesjulat6 by which the printorder spe cify various parameters such as style, cost, delivery 

wirHje-p rpc essed a n d s h ipped. options, shipping destination, and notifications. 

According to other aspects of the invention, a computer FIG. 8 shows a system in which a plurality of corporate 

program monitors changes to one or more corporate data- 45 databases within a single company arc monitored for 

bases and generates event data in response to such changes. changeSf and a lunU| of event ^ are defmed to handlc 

The event data is transmitted over the Internet to a central- evcnt data from cach database> 

ized print production facility, where the event data is used to , ^ a m for definj evem ^ 

fire one or more event rules, which in turn automa ically do cuments from information stored in a 

generate print requisitions or print production orders. In one 50 huma n reS0U rces database, 
variation, print requisitions are routed through an existing 

and commercially available procurement system, such as FIG - 10 shows a ?™ c ™ for Plating an event message 

Ariba™, before a print production order is generated. One structure. 

variation of the invention can monitor and handle event data FIG 11 s h° ws a user interface for defining event rules 

from multiple corporations, each having its own business- 55 relating to printing documents from information stored in a 

related event rules, and each potentially having its own manufacturing database. 

procurement approval system. FIG. 12 shows a user interface for defining event rules 

Fields in print requisitions and orders can be mapped to relating to printing documents from information stored in a 

corporate database schemas, such that different corporate sales management system database, 

identifiers for a particular data item (e.g., employee name) eo FIG I 3 shows a user interface for defining event rules 

arc mapped to a common data item in the print production relating lo printing documents from information stored in an 

facility. Moreover, some or all of a corporate database can be inventory control system database, 

mirrored at a central facility so that information for print FIG. 14 shows a user interface for defining event rules 

requests can be extracted locally rather than generating relating to printing documents from information stored in a 

further queries in the corporate database. 65 publishing system database. 

The inventive principles have broad application to various FIG. 15 shows a user interface for defining production 

types of corporate databases and ERPs. In a human rules for printing. 
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DETAILED DESCRIPTION OF THE The general creation and use of rules to perform further 

INVENTION processing is conventional and can be implemented using 

FIG. 2 shows a system that employs various principles of well-known expert system techniques (c.g PROLOG), for 

the present invention. As shown in FIG. 2, an event rule example. Customized rules could also be programmed 

generator 201 is used to generate one or more event rules 5 directly in software using programming languages such as 

mat are then stored into an event rules database 202. The Visual Basic LISP or the Idee. See US Pat No. 

term "event rule" will be used to refer to a rule that generates ^8 9 3,911 entitled Method for Denning and Applying 

an action in response to a business-related event, such as the Rules for Message Distribution for Transaction Processing 

addition of a new employee to a corporation; a change in 10 a Distributed Application/ assigned to Neon Software 

inventory levels for a product; orahfije.ceipt.oLan.qrderjQ io Inc ' Exam P les of vanous user interfaces that could be used 

manufacture a product- Other rules based- on parameters^ for establishing business related event rules are provided 

such as the passage of time could of course be definedj herein. 

Although it is expected that different companies will have \5\ Returning to FIG. 2, it is assumed that a corporate 
different event rules tailored for their particular business /database or ERP 203 contains information relating to a 

needs, it is of course possible to use the same set of rules for 15 particular application area, such as human resources, inven- 

more than one company. tory control, sales management, or the like. The database can 

According to the invention, event rules can be defined"\ comprise a relational or object oriented database, and data 



using any of various techniques such as a graphical user 
interface or a natural language tool. At least some of the 
rules may specify that one or more print production requ ests 
or requisitions is to be generated upon occurrence of a 



J» residing in the database can be queried a nd modified using 
well known data access conventions such as Structured 
Query Language (SQL). Any of various commercially avail- 
able databases such as Oracle, Sybase, or Informix could be 



business event. An example of an event rule might be: IF I used. It is of course possible that multiple databases co-exist 



(new-employee-added) THEN GENERATE 
(REQUISITION: business-cards USING new-employee- 



on a single computer, or one or more databases can be 
distributed across different computers in a corporation. 



information). The nature and number of the rules will of L A computer-implemented monitoring function 204 moni- 
course be dependent upon the type of business, the type of r tors corporate database 203 for changes. Monitoring func- 
database, and the type of ERP used by the company. In lion 204 can be configured to watch for changes to particular 
general, however, it is expected that event rules cause, ^either folds or tables in a corporate database (e.g., any change to 
alone or in combination with other rules, one or more print employee records), or it can be configured to generate event 
production requests to be generated using information perj 30 data whenever any change occurs. When a new record is 
taining to the event. added to the database, monitor 204 extracts some or all of 
The term "print requisition" will be used to refer to a print the new information ("event data") and transmits it to event 
request for which further approval or information is required manager function 205. For example, if a new employee is 
before the printing can be completed. The term "print added to the database, monitor 204 extracts the new employ- 
production request" will be used to refer to a print request 35 ee's name, address, and other information, and transmits the 
that can be executed without such intermediate approval or event data event manager 205. Mon itoring function ^2 04carjn 
additional information. Print requisitions and print produc- be configured to periodicall y query the databas eJ br. new 
tion requests may be referred generally herein as a "print recor ds, or it can be c onfig ured to inter ce pt database upda tes 
order." and generate event data"in response thereto. Moreover7tri5 
The term "event" will be generally used to refer to a 40 monitoring function can be implemented on a separate 
real-life event that can be detected (e.g., adding a new computer coupled to a computer on which the corporate 
employee, or a change to an inventory level), while the term database resides, or it can by hosted on the same computer 
"event data" will be generally used to refer to information as the database. 

concerning an event that has occurred (e.g., the employee's In some cases, subsidiary information may be required in 

name and other information). The term "event message" will 45 order to create a print requisition or print production request, 

be generally used to refer to event data that has been and other databases can be queried to create information 

augmented with some additional information in order to sufficient to create a print requisition or print production 

generate a print requisition or print production request. request. For example, when a new employee is added to the 

These terms are not intended, however, to be limiting. database, the billing and shipping information for business 

Moreover, the invention can be practiced without using 50 cards to be printed for the new employee can be extracted 

event messages altogether. from a different database. As another example, a particular 

Some event rules may not directly result in the generation company's graphics logo that is used on business cards may 

of a print requisition or a print production request, but may not reside in the corporate database 203, but may instead be 

instead set variables or store data into a database that causes stored in a different location. The subsidiary look-up func- 

other rules to fire. For example, a first rule could be defined 55 tions could be performed by monitor 204, by event manager 

that increments a new employee counter whenever a new 205 or by another software function. Such further informa- 

employec is added, and a second rule could be defined that tion may exist on a corporate database or it may exist locally 

generates a new order for business cards whenever the on a central print production server, 

number of new employees reaches five. | J_ Event manager 205 receives event data from monitor 204 

Moreover, some events may cause other events to fire. For 60 and, by executing rules stored in event rules database 202, 

example, if an organizational unit of a company changes its generates a print requisition to a procurement system 206. In 

name, then all employees belonging to that organizational one embodiment, procurement system 206 comprises a 

unit may require new business cards. A rule can be con- commercially available procurement product such as 

structed thai automatically queries all employees in the new Ariba™, Concur™, or Commerce One™. Such systems 

organizational unit and generates print requisitions for new 65 provide facilities for creating and updating purchase orders 

business cards (using the new organizational name) for all and obtaining approvals lo release the orders to vendors. In 

such employees. other embodiments, a print production request is directly 
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generated and provided to print production system 207 
without going through a procurement system 206. 

One possible print production system 207 is described in 
co-pending application Ser. No. 09/460,307, entitled "Sys- 
tem and File Structure for Consistent Visual Medium 
Materials," which is incorporated by reference herein. Print 
production system 207 may comprise a centrally located 
facility through which print orders can be received over the 
Internet from a plurality of companies. Imaging system 208 
and print processor 209 are conventional. Imaging system 
208 may comprise any of various types of devices that 
generate print media such as printing plates or sheets on the 
basis of an electronic file, and print processor 209 performs 
the actual printing, embossing, engraving or the like in order 
to generate printed products 210. 

In one embodiment, print production system 207 can 
transmit print ord ers to multiple vendors, suclLas_Vendor A 
and Vendor B shown in FIG. 2. In this manner, different rules 
can specify that certain types of print production tasks are to 
be routed to one geographic print location, while other types 
of print production tasks arc to be routed to another geo- 
graphic print location. For example, if business cards are to 
be printed for a new employee at the California location of 
a company, the actual print job can be routed to a print 
vendor located in California, in order to minimize shipping 
costs and expedite delivery. A print job for an employee 
located in New Jersey might be routed to a New York City 
vendor for the same purpose. In one embodiment, a software 
function in print production facility 207 locates the print 
vendor nearest to the shipping location. The print production 
system can be coupled to different vendors over the Internet, 
by facsimile, or by other methods. 

Rules can be created to select vendors based upon other 
criteria, such as ownership of the vendor or the business 
practices of the vendor. For example, some municipalities 
require that, in order to enter into a contract with the 
municipality, an organization subcontract a percentage of 
services to minority-owned businesses. Alternately, some 
organizations desire to only employ services from environ- 
mentally friendly companies. Accordingly, rules can be used 
to select vendors based upon ownership of the vendor or the 
vendor's business practices. 

More generally, r ules can be used to specify various cost , 
schedule, delivery, location , print quality, shippin g, and 
other parameters associated with print jobs. Turning briefly 
to FIG. 7, a rule can be defined that is fired whenever a new 
employee is added to Company X's corporate database. The 
rule can specify that upon such an event, a print production 
re quest for new business ca ,rrk he. genera ter j^ usin g a par- 
ticular pre-defined business card style for Company a. ine 
rule can also specify that the business card be generated 
using information regarding the new employee extracted 
from the event data (i.e., extracted from the corporate 
database), wherein additional information such as billing 
information can be extracted from other data sources. 
Moreover, the creator of the rule can specify that the cost 
must be less than $20 for a set of business cards, thus 
causing print production system 207 to locate a print vendor 
that can satisfy this requirement. Alternatively, rules can be 
used to optimize multiple print production requests into a 
print job that can be routed to a vendor able to satisfy the 
requirement. 

The rule can also specify a delivery constraint (e.g., must 
\j be delivered within 3 days), which can be used by the 
software to locate a print vendor that is within a 3-day 
shipping area of the shipping address (or is willing to ship 
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on an expedited basis within that constraint). A shipping 
address can also be specified, and if necessary can be 
queried from the corporate database or other location. 
Finally, a notification option can be specified in order to 
5 notify the employee and the human resources administrator 
when the order is shipped. Other variations are of course 
possible, and the example of FIG. 7 is not intended to be 
limiting. 

Turning now to FIG. 3, a system that incorporates various 

10 principles of the invention in an Internet environment (or 
similar network) will be described. It is assumed that a 
corporate database 301, a database monitoring function 302, 
and a corporate procurement system 306 is located at a 
company facility 350. Additionally, it is assumed that moni- 

15 toring function 302 and corporate procurement system 306 
are accessible through the Internet 307 using conventional 
protocols such as HTTP, FTP, and the like. Event manager 
304, event detection function 303, event rules database 305, 
and mirrored database 312, along with the other functions on 

20 the right side of FIG. 3, are assumed to reside at a centrally 
located print production facility 360 that is similarly acces- 
sible over the Internet 307. It will be appreciated that certain 
of the functions can be centrally located, while others (e.g., 
imaging system 309 and/or print processor 310) could be 

25 located at a separate facility. 

. Database monitoring function 302 comprises software 
^ that is tailored to the company's corporate database 301 to 
monitor changes to certain fields in corporate database 301 
and7 in response thereto, gener ate event data that is trans - 

30 mi tted over the Internet or other network to event detection 
function 303 at the central print production facility 360. 
Database monitoring function 302 may be implemented on 
a separate computer from corporate database 30 1, or it may 
co-exist on the same computer. According to one- 

35 embodiment, database monitoring function 302 and event 
detection function 303 use the commercially-available Web-, 
Methods Server soft ware in order to ^sxjr act and transmit .. 
infom ^tion_over tne internet , It will be appreciat edjhal 
ms^a^ofllheJrjtc rjict. other types of networks such1islocal_ 

40 ar ea networks and the like can be used . 

Event detection function 303 receives event data from 
monitoring function 302, converts each into an event mes- 
sage that forms the predicate for one or more rules in event 
rules database 305, and passes the event message to event 

45 manager 304. Where necessary, database fields in corporate 
database 301 are mapped to fields used internally by prinl^ 
pr qduction.faci lity_360 to create printed produ cts, and this 
mapping can be done iiTmonitoring function 302, event 
detection function 303, or event manager 304. As explained 

50 above, conversion of event data into an event message 
structure may require supplementation of data such as 
billing information and the like, although such a step may 
not be required. Database monitor 302 and event detector 
303 can be located on either client side 350 or print facility 

55 side 360, depending on design requirements. 

Turning briefly to FIG. 6, a first company (Company X) 
might use a certain database schema that contains fields 
identified as EMPLOYEE-NAME, EMPLOYEE-TITLE, 
and the like. A second company (Company Y) may refer to 

60 similar data items in its database as ENAME, ETITLE, and 
so forth. Fields in different corporate schemas 601 and 603 
can be mapped to a common schema 602 within print 
production facility 360, such that an instance of a field for 
EMPLOYEE-NAME from Company X is stored into a 

65 generic NAME field in the print production facility, and an 
instance of a field for ENAME from Company Y is stored 
into the same named field in the print production facility. 
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Similarly, data that does not reside in either company's 
database can be stored locally within print production facil- 
ity 360 in a separate database 604 having fields mapped to 
the common schema 602. For example, a "logo" field that 
refers to a graphical logo that is to be printed on a company's 
business cards may be stored separately in a logo database 
604 at the print production facility. References to each 
company's logo aspartofaprint order will cause the logo 
Jd be retrieved locally from database 604. 
V *V Returning to FIG. 3, in one embodiment event manager 
304 executes event rules and, in response thereto, generates 
a print production request to print production system 308. In 
another embodiment, event manager 304 executes a rule that 
causes a print requisition in the form of a procurement order 
to be generated and sent to corporate procurement system 
306 for approval. Such a request can be sent over the'*-. 
Internet, and approval returned in the same manner. After [ 
receiving approval, a print production request is generated 1 
and passed to print production system 308 for execution. -J 



10 



15 



included in the request, verifies the completeness and cor- 
rectness of the resulting structure, and places the request in 
a queue for processing. 

t According to one variation of the invention, event queues r 
m ay be used to temporarily hold event messages until 
a nother specified e vent occurs (for example, the passage of 
a period of time)'. 'Cjueues cacTbe used on the client or 
corporate side 350 of the system of FIG. 3 (e.g., in connec- 
tion with database monitor 302), or they may be placed on 
the print production facility side 360 of FIG. 3. For example, 
event messages can be queued until the end of a business 
day, or until a specified number of events (e.g., ten or more 
events) have occurred. Additionally, events can be condi- 
tioned on the occurrence of other events. 

It will be appreciated that the various functions illustrated 
in FIG. 3 can be located on the client side (350) instead of 
at a central print production facility (360), and that various 
functions may be combined for purposes of design and 
efficiency. Consequently, the architecture shown in FIG. 3 is 



Event manager 304 can also automatically notify a corporate-20 intended to be exemplary only. For example, at a portion of 
employee (e.g., via e-mail) to confirm that the order was / the event detection function may be combined with the 
placed. The latter -notification can include an estimated / database monitor 302 on the client side 350. This allocation 



com pletion a n d shipment date for the orde r. ' — J 
Event manager 304 can be implemented as a queu e -driven 



of function would help reduce the number of actions to be 
handled by event detection function 303 and event manager 



process that retrieves a next event from the queue; retrieves r 5 304. In this instance, the database monitor 302 could store 
any business rules that apply to that event, and performs the 
actions that apply to that event. Different sets of event rules 
for different companies can be stored in event rules database 
305 and retrieved according to the company from which an 
event was generated. Moreover, event manager 304 may 
generate additional events based on the firing of certain 
rules. For example, if an organizational change occur s, a rule 
can be fired that auto matically queries all employee s 
affected b 



30 



i nizartonal cha nge and generates ajsqnt 

re quisition for each new employee to crea^ ^ew business 



3S 
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cards_f or those employees. In certain embodiments, it may 
also be possible to pass event data directly to event manager 
304 without processing by event detection function 303. 

In one embodiment, a mirrored database 312 is main- 
tained at the central print production facility 360, such that 
database changes in corporate database 301 are transmitted 
to mirrored database 312. When additional information is 
needed for a print request, it can be extracted directly from 7 
mirrored database 31 2 instead of querying corporate data - 
b ase 301 . In yet another variation, monitoring function 313 
can be located at the print production facility and used to 
monitor changes to mirrored database 312 instead of hosting 
such monitoring functions at the corporate facility. In this 
case, some mechanism for maintaining synchronization 
between the databases would be needed (e.g., peri odic batch] 

u pdates or the like ), as is known in the art. " 

Certain types of print requisitions may require additional 
information, such as a billing or shipping address for the 
print production request. This additional information can be 55 
extracted from corporate database 301, from mirrored data- 
base 312, from a local database maintained at the print 
production facility 360, or provided by corporate procure- 
ment system 306. 

In one embodiment, print requests are generated w henan 60 
external progjiDuneiUjeguest is generated. According to this 



embodiment, a co mpany employee uses a commercially 
available procurement system to request a print job (e.g., 
new business cards). The procurement system recognizes 
the request as one to be directed to a print vendor, and 65 
tra nsmits the req u^Uo^&vsntjHariage r 304 ov er the In terne t. 
Event manager 304 fills in customer-specific' dctails~not 



event rules and include a queue that stores database actions 
until an event is to be generated. 

FIG. 4 shows an alternate embodiment in which a plu- 
rality of companies 401 and 402 are coupled to a print 
production facility 406 through the Internet, and wherein a 
first company 401 uses a corporate procurement system 403 
for approval of print requisitions, while a second company 
402 does not use such a procurement system. This embodi- 
ment illustrates how a central print production facility 406 
can handle different types of requirements from different 
companies. 

FIG. 5 shows steps that can be carried out to implement 
various methods of the invention. Beginning in step 501, one 
or more printed products are defined, and the data content 
required for each product is mapped to one or more fields at 
the print production facility. For example, a business card 
product may comprise various common fields such as name, 
title, address, telephone number, corporate logo, and the 
like. Additionally, certain formatting information such as the 
size, shape, color, and other parameters of the business card 
are specified, This information collectively defines one type 
of printed product (e.g., business card type A). Step 501 may 
be performed with respect to a user interface as shown, for 
example, in FIG. 15. 

In step 502, events that can occur in the system are defined 
and mapped to one or more corporate database fields. For 
example, an event message NEW-EMPLOYEE-ADDED 
can be defined to occur when a new employee record is 
added to the corporate database, and various fields from that 
record are mapped to corresponding fields in the print 
production facility (see FIG. 6). Some rules can be created 
such that they are triggered automatically upon passage of a 
certain quantity of time (e.g., check an inventory level every 
5 days, or print a new catalog once a year based on the 
current state of a parts database). 

In step 503, company-specific event rules and correspond- 
ing actions are denned. As one example, when a new 
employee record is added to the corporate database, a print 
requisition for 1,000 business cards, a new name plaque, and 
customized letterhead for that employee will be automati- 
cally generated, using data extracted from the corporate 
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database (i.e., without human input). If the employee is a 
sales employee, then sales brochures or other pertinent 
printed products can be generated. 

As a further example, a company may have a specific 
business rule that states that if a sales person exceeds his or 
/ r-^her sales quota for a given quarter, that salesperson may 
r I order a special set of business cards and stationery items. In 
1 ^"ihis example, events can be denned (step 502) such that once 
an individual sales quota is exceeded, two actions will be 



In step 507, a print production request is generated, again 
preferably using information extracted from the corporate 
database rather than manually entered information. 
Additionally, a uotification feature can be provided, such 
that an e-mail message is transmitted to a predetermined 
employee (or to the employee whose prini^prodjicts were 
automatically ordered) confi rmmg thal the print order w as *n *1 
siihmitieri r jmn^royidingra iTf-^^ and/oi \ ( 

shij^mgjdat&. — ' 

none embodiment, a notification or shipment request can 



performed by step 504. One action may be to grant ordering In one embodiment, a notification or shipment request can 
privileges to the special product set, and the second action VJ^ also be generated for a vendor to schedule further action on 
may be to se nd a notification to the salesperson informin g ( z_ .^particular date. For example, if it is determi ned that the 
them ot their abili ty to order these products. This example pjafoft wiiLbe cnmpletedjn (wo days and result in a certaip 
loeTlioT e x' C t ud r'nie possibility that a print production quantity of paper products^ an advance notification can be 
request could be generated directly (step 507). 15 transmitted-to-a-SKipping vendor to scljedule_rjicJtzUp_of a 

predetermined number of boxes on the datethat the print job 
will be completed. 

Finally, in step 508 the printed products are generated. 
These may comprise paper products, plaques, embossed 



As another example, if a new p roduct order is added to the 
database, a print requisition for a number ofprinted products. 
(instruction books, warranty cards, and the like) correspond- 
ing to the number of products ordered will be automatically 



Id Leenerated. Again, it is preferred that no human manually 20 items, packages, container labels, and the like. 



enter information such as numbers or product codes in order 
to generate the print request, in order to minimize human 
intervention and avoid data entry errors. 

Step 503 may also include interacting with a user inter- 
face. The user interface may take the form of displays on a 
screen similar to those shown in FIGS. 9, 11, 12, 13, and 14. 
After interacting with the user interface, the event rules may 
be saved into event rules database 202. 

Rules can be defined to perform any of various actions 
when triggered by an event. Some examples include: 

(1) Send an e-mail regarding notification or scheduling of 
a future event; 

(2) Create, cancel, or approve a purchase order; or update 
a database record in a central print production facility 
(including checkpointing or taking a snapshot of a 
corporate database); 

(3) Perform an external procurement operation (e.g., 
through a commercial system) 

(4) Perform an action on an external customer corporate 
data (e.g., update an employee record, update an inven- 
tory record, or insert a purchase order number); 

(5) Perform an action on a print vendor's system (e.g., add \ 
job, cancel job, etc.); 



FIG. 8 shows a system in which a plurality of different 
types of corporate databases, such as human resources 
database 803, sales database 804, and manufacturing data- 
base 805, are monitored in order to generate event data to an 
25 event detection function 809. Event detection function 809 
generates event messages that are handled by event manager 
810, which applies separate rules tailored for each type of 
database. For example, one set of human resource rules 806 
may apply only to events occurring in the human resources 
30 database 803, while sales rules 807 pertain only to events 
arising from sales database 804 and manufacturing rules 
apply only to events occurring in manufacturing database 
805. Although separate monitoring functions are showo in 
FIG. 8 to allow for the possibility that the databases may 
35 reside on different machines at different locations, the moni- 
toring functions and databases could of course be combined 
into a single machine at one or more locations. 

A more detailed description of one possible approach for 
allowing a user to define various types of event rules in the 
40 system will now be provided with reference to FIGS. 9 
through 16. Various user interface techniques, such as form- 
\ driven web pages, can be used to accept user input to define 
event rules. As discussed above, rules can also be specified 
in a declarative language such as PROLOG or the like and 



(6) Perform an action on an external manufacturing Is executed by an inference engine. Combinations of the two 
tracking system, such as HAGAN™ (e.g., create a job ' are also possible, such that a browser-based form input tool 
in process, update job in process, etc.). is used to generate declarative rules, which are then inter- 
An automatic procurement action can be initiated based preled by an expert system or inference engine, 
on detection of an event. For example, if a new employee is Referring to FIG. 9, a user interface is shown for receiving 
added to the corporate database, a procurement order can be 50 input relating to designation of event rules. The user inter- 
automatically generated to request that a certain predeter- face includes a first selection 901 in which a user designates 
mined set of personalized office supplies such as letterhead, the type of printed product to be generated. A second 
envelopes, business cards, and the like be ordered and ^ selection 902 allows the user to designate when an action or 
shipped to the new employee's address. Q&V 1 ^ event wi H trigger the rule, and includes a pull-down menu 



In step 504, events in the system are detected and rules 
fired based on changes to the corporate database. 



Alternatively, evenfmessages may be generated in response" 
to a manually entered procurement order. 

In step 505, a print requisition is optionally generated 
using data extracted from the corporate database 

necessary, from other sources (e.g., logo image files; 

and shipping addresses). As explained above, requisitions 
could be avoided and print production requests directly 



55 903 that specifies various types of events that can occur in 
the database to which the rule pertains. According to one 
embodiment, the events correspond to changes to pre- 
defined columns in a database table (e.g., new employee, 
changed telephone number, and the like). 
6 °.*V Op 1 * 00 90*4 allows the user to specify when the print 
i ^production job should be released, and may include a variety 
of options 905, 906, and 907. For example, as indicated at 
905, the print job can be released automatically, so that the 
printing is initiated immediately after detection of the event. 



generated id certain embodiments of the invention. If a print 
requisition is generated, then in step 506 approval of the 65 Alternatively, the print job release may be conditioned on 
requisition occurs, either through a commercially available various factors such as whether an optimum number of print 
procurement system or some other mechanism. jobs has been received in a queue (optimum in the sense that 
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multiple print jobs can be combined for efficiency); whether 
a certain number of print requests has been received; 
whether a certain number of days has elapsed. 

An optimum number of print jobs may relate to specific 
conditions of the printing production system 308 of FIG. 3. 
For example, as is known in the art, business cards are 
generally printed in batches consisting of groups of four, six, 
eight, etc. cards each. A printer attempts to minimize set up 
and break down costs for a printing press by placing as many 
different cards on each printing plate or die as possible. By 
increasing the number of cards on the plate or die, the longer 
the run length of the printing press. Because setting up and 
breaking down a press run involves certain fixed costs, 
overall costs can be minimized by spreading the fixed costs 
over as many printing jobs as possible. The ability for the 
client to specify that the rule is only to be fired when there 
are an optimum number of print jobs thus may reduce costs 
to the client. 

Finally, user interfa ce portion 906 allows for a default 
r elease after a seated number oLdajs . If a queue resident 
on event manager 304 contains actions' that are older than a 
specified number of days , the queue will be flushed and the 
eventmanager 304 will initiate the print production requests 
for items in the queue. 

User interface selection 907 allows a user to designate 
that the job will need to be approved prior to releasing the 
job. Id this situation, the user would enter the information 
regarding who will provide approval. In some cases, mul- 
tiple approvals may be required. Where at least one person 
or process has been designated to approve a job, the occur- 
rence of an action satisfying the criterion of 903 instructs 
event manger 304 to generate a request for approval from 
corporate procurement system 306. In an alternative 
embodiment, corporate database 301 can be updated with an 
indication that approval has been sought, thus causing 
database monitor 302 to monitor corporate database 301 for 
an indication that the print job has been approved. At that 
point, database monitor 302 would transmit an approval 
action to event detection 303, which would then generate an 
approval event for handling by event manager 304. 

Selection option 908 allows the user to specify shipping 
information (e.g., ship when order complete, h old until a 
HpifmatRd time, and fhip lo fl.desif ned-feBtilv,V Option 909 
includes a button for saving the entered information. It is 
appreciated that additional screens may be used to input 
information and the actual saving of information can only 
occur after all information has been entered. 

FIG. 10 shows an example of a pr ocess for populatingj w 
event structure. In FIG. 10, an emplo3 ? eeTecord is updated 
(step 1001). The change in the database storing the 
employee record is detected (step 1002). An event structure 
(reporting the change) is populated (step 1003) with infor- 
mation regarding the change as detected in step 1002. In the 
situation where certain additional information (not supplied 
with the detected change) is needed, such additional infor- 
mation is retrieved in step 1005 and populated into the event 
structure (step 1004). Alternatively, the additional popula- 
tion steps could be performed on the print production system 
side 360. — 

In step 1006, the event structure is checked for complete- 
ness and correctness. If additional information is needed to 
fulfill the print request (for example, the specific corporate 
logo or template to use), this information is retrieved from 
database 312 (step 1006) and the completed order placed in 
an event production queue for processing (step 1007). 
' FIG. 11 shows a user interface for defining event rules 
relating to printing documents from information stored in a 



manufacturing database in accordance with embodiments of 
the present invention. Like the interface of FIG. 10, a first 
selection item 1101 allows a user to specify what printed 
product is to be generated when the rule fires. Interface 
5 portion 1102 allows a user to determine when the sel ected 
item in 1101 is to be printed. In some embodiments/aTleast 
two different situations are possib le: the time that a design 
is released by one or more entities; and the time that a new 
product order has been placed. Selection option 1103 allows 
io the user to select the product for which the item to be, — 
printed. 

FIG. 12 shows a user interface f or defining event rules 
relating to prinlirrg*o L ocuments irom information stored in a 
sale s management system database . Selection option 1201 
15 relates to the type of sales product to be generated (for 
example, sales packet ho. 1, sales packet no. 2, etc.). 
Seleclion item 1202 allows the user to identify the event that 
will trigger the rule (for example, new contact added to 
database, new status of contact moving to level 2, new status 
20 of contact moving to level 3, and the like). Selection option 
1203 allo ws the user to specify where the printed product , 
sh ould be shipp ed. For example, the printed information 
may be shipped'to the salesperson or the contact. 
FIG. 13 shows a user interface for defining event rules'^ 
25 relating to printing documents from information stored in a 
inventory control system database. User interface portion 
1301 includes the type of item to be printed (for example, a 
flyer, a brochure, etc.). As database monitor 302 fires actions 
to event manager 304 through event detection 303, interface 
30 portions 1302 and 1303 indicate when an event has occurred 
for print processing. Interface portion 1402 allows a user to 
specify that an event has occurred when inventory falls 
below an adjustabl e numb er. In this example, database 
monitor 302^m^)rrttors the~inventory in corporate database 
35 301 and forwards inventory changes to event manager 304 
through event detection function 303. S election option 1303, 
allows t he user to specify that the printed product should be 
gen erated according to a specified time interval. 
/&£y~FIG. 14 shows a user interface for defining event rules 
?D relating to printing documents from information stored in a 
wrf publishing system database. User interface portion 1401 
J allows the user lo select the type of item to be printed 
I (reprints, covers for magazines, etc.). Interface portion 1402 
I * allows the user to specify that a print order should be 
M5| generated when the number of orders for a given item" 



I * allows the user to specify that a print order should be 
M5| generated when t he number of orders for a given item 
I f_ gxeeed a specified numbe r. Ihjs^could be beneficial whe n ^ 
J the set up c osts for producin gasi rialt number of reprints is. I 
j relatively High per reprint. By setting a minimum number of J 
orders to be'pta^eUbtfore executing the reprint order, th e^gt^ 
up costs may be spread over a larger number of orderf fj. 
Interlace portion 1403 allows tor the flush ing"~of an ordeV 
queue after a given number of weeks. For example, if a 
publishing house needs to complete all orders by a given 
time, all orders may be processed at a chosen time as 
55 specified in interface portion 1403. Interface portion 1404 
allows seleclion of the title to be printed. The seleclion of the 
title may also include selection of a portion of the title as 
well. For example, one may specify to reprint an entire 
magazine. Alternatively, one may separately specify to 
60 reprint selected articles for the magazine. Finally, interface 
portion 1405 allows for the user to select a specified overrun 
to allow for any subsequent orders. A percentage overrun 
may be beneficial where the publisher knows that subse- 
quent orders may likely be received, but wants to c reate a 
65 stock pile of reprints at a given time ( for example, pnor to 
receiving all orders). This allows the publisher to not have 
to reset presses for running a short reprint run. 
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FIG. 15 shows a user interface for defining production 2. The method of claim 1, wherein step (3) comprises the 
rules for printing. User interface portion 1501 allows the step of automatically generating a procurement request that 
user to select a specified product. These production rules requires approval by a corporate employee; and 
may also include designation of the customer (for example, further comprising the step of approving the procurement 
company X as opposed to company Y). Sub designations 5 request before the printed product is produced, 
may also be made for various individuals in the company 3. The method of claim 2, further comprising the step of: 
through interface portion 1502. Interface portion allows for transmitting the procurement request to a procurement 
selection of the media type for the printing of the item system located at the corporate facility, 
selected in interface portion 1501. For example, for business 4. The method of claim 3, further comprising the step of 
cards selected in interface portion 1501, the customer may 1Q transmitting the approval lo the print processing facility 
wish to have one card stock for management and a different which, in response thereto, produces the printed product, 
card stock for sales personnel. Interface portion 1504 allows 5, The method of claim 1, wherein the print order com- 
for different templates to be specified. Interface portion 1505 prises a print production request that is directly fulfilled by 
allows a user to specify which logo to use for a given printed a print production system without further approvals, 
item (for example, if a blue logo is to be used for sales v. a 15 6. The method of claim 1, further comprising the step of 
gold-embossed logo for management). Interface portion checking one or more print criteria that must be satisfied 
1506 allows for reporting (and approval, if specified, in before the printed product is actually produced, 
interface portion 1508) to be made to various entities of a 7. The method of claim 6, wherein the checking step 
client. Interface portion 1507 allows for selection of a comprises the step of checking a cost parameter that speci- 
client's database thai holds additional information. For 20 fies a cost below which the printed product must be pro- 
example, a client may wish to maintain all content image duced. 

files for printing. If the image file was not forwarded with the 8. The method of claim 6, wherein the checking step 

event as reported to event manager 304 and if the client comprises the step of checking a delivery parameter that 

maintains the actual image file, user interface portion 1507 specifies a delivery deadline by which the printed product 

allows the specification of the database. Also, for secure ^ must be produced. 

environments, the interface portion may include authentica- 9. The method of claim 6, wherein the checking step 

tion and verification information 1507 needed to access the comprises the step of checking a shipment address that 

client's database. Interface portion 1508 receives user input specifies a delivery address for the printed product and 

to hold a print order until approval has been received from selecting a print vendor located near the shipment address to 

another entity. Finally, interface portion 1509 allows a user 30 produce the printed product. 

to select a printer based on some criteria. For example, a 10. The method of claim 6, wherein the checking step 

printer may be selected by location (close to a specified zip comprises the step of checking one or more print criteria to 

code) or chosen by ownership (e.g. jobs may be earmarked select one print vendor from among a plurality of print 

for printing by minority-owned businesses). vendors to print the printed product. 

The principles of the invention can be applied to not only 35 11. The method of claim 1, further comprising the step of 

traditional pape r printed products, but to electronic docu- notifying a corporate employee via e-mail of the print order, 
ments as well. For exaraple"7~the invention can be applied to*^ 12. The method of claim 11, wherein the corporate 

publish electronic documents an d "deliver" them to Internet / employee is specified in one of the predefined event rules, 

web pages, discussion groups, e-mail systems, collaboration | 13. The method of claim 1, further comprising the step of 
portals, and to enterprise systems. All of the foregoing! 40 transmitting over the Internet the event data to the print 
would be examples of database-driven means for commu-j processing facility. 

nicating and publishing digital information. -J£\Z 14. The method of claim 1, further comprising the step of 

Thus has been described various systems, methods and retrieving corporate-specific information in addition to the 

techniques for generating print production requests accord- event data and using the corporate-specific information to 
ing to events that occur in a corporate database. Any of the"L, 5 generate a print production request, 

method steps described herein can be implemented in com- Lt 15. The method of claim 14, wherein the corporate- 
puter software that is sto red on a computer-readable medium" *? specific information comprises a corporate logo that is not 
such as a magnetic disk or CD-ROM. Many variations undiJ* stored in the corporate database. 

alterations of the invention are _ of course possible. 16. The method of claim 1, wherein step (3) comprises the 

Consequently, the invention should be limited only by the 50 step of generating a print production request to produce the 

appended claims and their equivalents. printed product without any human intervention at the 

What is claimed is: corporate facility and without any human intervention al the 

1. A method for producing a printed product in response print production facility, 

to changes in a corporate database, the method comprising 17. The method of claim 1, further comprising the step of 

the steps of: 55 translating at least some of the event data into a common 

(1) monitoring the corporate database to detect changes print production request based on a schema mapping 
corresponding to a corporate event; between fields in the corporate database and fields stored in 

(2) in response to detecting a change in step (1), gencr- the print processing facility. 

ating event data comprising information that describes 18. The method of claim 1, further comprising the steps 

the corporate event; and 60 °f ; 

(3) in a print processing facility, receiving the event data, maintaining a periodically updated copy of at least some 
comparing the event data to one or more predefined of the data stored in the corporate database; and 
event rules that determine whether the printed product in the print processing facility, using the periodically 
should be produced and, in response to a positive updated copy to retrieve information used to satisfy the 
determination, automatically generating a print order 65 print order. 

for the printed product using information extracted 19. The method of claim 1, further comprising the step of 

from the event data. generating in the print processing facility a plurality of print 
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orders each comprising an order to print a different type of 
printed product. 

20. The method of claim 1, further comprising the step of 
communicating between the print processing facility and a 
plurality of geographically diverse print vendors through a 5 
communication network. 

21. The method of claim 1, further comprising the steps 

of: 

(4) monitoring a second corporate database to detect 
changes corresponding to a second corporate event; 10 

(5) in response to detecting a change in step (4), gener- 
ating second event data comprising information that 
describes the second corporate event; and 

(6) in the print processing facility, receiving the second 15 
event data, comparing the second event data to one or 
more predefined event rules that determine whether the 
printed product should be produced and, in response to 

a positive determination, automatically generating a 
second print order for the printed product using infor- 2Q 
mation extracted from the second event data. 

22. The method of claim 1, wherein the corporate data- 
base comprises a human resources database, and wherein the 
corporate event comprises the addition of a new employee to 
the corporation. ^ 

23. The method of claim 22, wherein the print order 
comprises an order to print business cards for the new 
employee. 

24. The method of claim 1, wherein step (1) comprises the 
step of monitoring a sales management database for a sales 
event. 



25. The method of claim 1, wherein step (1) comprises the 
step of monitoring a manufacturing database for a manu- 
facturing event. 

26. The method of claim 1, wherein step (1) comprises the 
step of monitoring an inventory control database for a 
change to an inventory level of a product. 

27. A method of generating a printed product in response 
to changes in a corporate database, comprising the steps of: 

(1) in a computer, detecting changes to the corporate 
database corresponding to a corporate event and, in 
response thereto, generating event data comprising 
information that describes the corporate event; and 

(2) comparing the event data to one or more predefined 
event rules that determine whether the printed product 
should be produced and, in response to a positive 
determination, automatically generating a print order 
for the printed product using information extracted 
from the event data. 

28. The method of claim 27, further comprising the step 
of generating a procurement request to a procurement sys- 
tem and, upon receiving an approval from the procurement 
system, generating the print order. 

29. The method of claim 28, 

wherein step (1) is performed at a corporate facility; 
wherein step (2) is performed at a central print production 
facility; and 

further comprising the step of transmitting the event data 
over the Internet to the central print production facility. 
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